무한 스크롤링 호출 시점 변경 - #10
Conversation
2. 검색 버튼 사용시 list초기화 시점을 call back 안으로 옮김
2. 검색 버튼 사용시 list초기화 시점을 call back 안으로 옮김
|
|
||
| // 검색버튼에 의한 호출일 경우, 기존 list 비우기 | ||
| if(currentPage == 1) { | ||
| adapterModel.clearItems(); |
There was a problem hiding this comment.
isRefresh 조건 안에서 기존 list를 비우지 않고 api 호출후 하는 이유가 궁금합니다.
There was a problem hiding this comment.
검색 API 호출은 비동기적으로 구현되어 있기 때문에 공유자원(itemList)에 대한 Race Condition 문제가 발생할 수 있습니다.
이를 해결하기 위해 해당 코드는 비동기 호출이 완료될 때까지 공유자원(itemList)에 대한 점유권(쓰기 작업)을 호출 원인(검색 버튼 또는 스크롤링)이 소유하도록 isLoading 변수를 사용하여 임계 영역을 구현했습니다.
CallBack 내부로 itemList 갱신 코드를 옮긴 것은 공유자원에 대한 접근 코드를 임계 영역으로 옮긴 것이 됩니다.
적고 보니 isLoading.set(false)를 모든 작업을 마친 뒤에 호출하는 것이 옳아 보입니다. 감사합니다!
There was a problem hiding this comment.
isLoading.set(false)의 위치에 따라 성능적으로 어떻게 차이가 나는지 알 수 있을까요?
There was a problem hiding this comment.
제가 섣불리 판단했습니다..
마지막에 배치한 의도는 데이터 처리까지 완료한 후에 ProgressBar 를 중단 시키려고 했습니다,
하지만 검색 결과가 없을 시에 중간에 return 구문으로 종료함으로써 계속해서 ProgressBar 가 표시되는 문제가 발생합니다. 지적해주셔서 감사합니다!
|
|
||
| private String searchKey = ""; // 검색 키워드 | ||
| private final int PAGE_UNIT = 20; // 한번에 가져올 데이터 개수 | ||
| private final int PAGE_UNIT = 10; // 한번에 가져올 데이터 개수 |
There was a problem hiding this comment.
20개씩 호출은 마지막 5번째 아이템까지 닿는데 여러 번 스크롤을 해야 합니다. 스크롤을 두세 번만 내리면서 API가 연속적으로 잘 호출되는지 확인하고 싶었습니다. 감사합니다!
4 participants
개요
기존 무한 스크롤링 호출 시점은 저장된 아이템들 중 제일 마지막 아이템이 화면 바닥에 노출될 때입니다.
(수직으로 스크롤을 더 이상 할 수 없을 때)
사용자는 부드럽게 내려가던 스크롤이 갑자기 멈추는 경험을 합니다.
부드러운 움직임을 유지하고자 호출 시점을 저장되어 있던 아이템들 중 끝에서 5번째 아이템이 화면에 노출될 때로 수정했습니다.
작업사항
onScrollStateChanged 함수 수정
무한 스크롤 호출 테스트를 위해 기본 호출 개수를 20개에서 10개로 수정
검색 버튼에 의한 list 수정을 call back 에서 후처리하도록 수정
감사합니다 ! :)